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Abstract: 

The amount of traffic generated by Real Time Applications has increased substantially 
over the years. RTA will face congestion where there is any form of bottleneck restricting traffic. 
This will result in packet loss or delayed traffic which is unacceptable for RTAs. Therefore it is 
desirable for RTAs to implement congestion control mechanism to improve the stability of 
networks. 

TCP Friendly Rate Control (RFC 3448) is a congestion control algorithm that provides a smooth 
transmission rate for continuous flow of data is available at sender. So it does not suitable for 
RTAs where data rate changes abruptly. RFC 5348 works based on variable bit rate for RTAs. 
TFRC RFC5348 has been proven to be fair when competing with TCP flows over congested 
links, but it lacks quality-of-service parameters to improve the performance of real-time traffic. In 
this work we use NS2, the network simulator for simulation of TFRC. TFRC is simulated in 
wireless environment, limitations are identified and modifications are proposed. 
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1. INTRODUCTION 

The Transmission Control Protocol (TCP) is connection oriented protocol that provides 
reliable and ordered delivery of packet and also provides end-to-end congestion control 
mechanism. Data transfer applications such as HTTP, FTP and SMTP are based on TCP. But over 
Internet, the use of RTAs such as VoIP, video conferences, instant messaging is constantly 
growing. Estimates show that these streaming media accounted for 30% of overall internet traffic. 

The user datagram protocol (UDP) is one of the protocols of the Internet protocol suite. 
Using UDP, programs on networked computers can send datagram's to one another. UDP 
applications can send data at constant bit rate where it does not guarantee reliability or ordering in 
the way that TCP does. It is one of the non TCP based protocol. This non TCP flow cannot adjust 
their flow rate when congestion is detected where it continue to send at original rate. So these non 
TCP applications do not have congestion control mechanism and do not share bandwidth fairly 
with TCP based applications. 



A new congestion control protocol for datagram transport was defined i.e., TFRC 
standardized by Internet Engineering Task Force (IETF). It provides a smooth transmission rate 
for real-time applications.lt is reasonably fair when competing for bandwidth with TCP flows. In 
RFC 3448 a TFRC algorithm is defined based on model of TCP and it is designed for continues 
flow traffic. This is not suitable for the applications whose transmission is variable bit rate. 
Datagram congestion control protocol (DCCP) is recently standardized protocol. DCCP supports 
multiple congestion control algorithms and these will be selected through its Congestion Control 
ID (CCID). Three CCIDs are now standardized by IETF. CCID2 is a window based congestion 
control algorithm similar to TCP, CCID3 is a TCP-Friendly Rate Control algorithm, and CCID4 
is a TCP-Friendly Rate Control for Small Packets (TFRC-SP). 



In this paper, we present results of experimental evaluation of the performance DCCP (CCID3) 
TCP-Friendly rate control over wireless environments. 



2. How TFRC works 

TFRC functionalities are located at the receiver's side. TFRC adjusts its sending rate 
based on the complex TCP throughput equation shown below: 
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T(Bps) 



RTT l^+RTOl 3 )p(l+32p 2 ) _ 




Where: 

• s is segment size in bytes, 

• RTT is round trip time in seconds, 

• RTO is the TCP retransmission timeout value in seconds, 

• P is the loss event rate. 



To calculate loss event rate, receiver needs to find loss event of one or more packets lost or 
marked in particular RTT. Timestamp along with RTT is used by receiver to determine losses 
belong to same loss event or not. RTT is used to determine when to send feedback packets. Loss 
event rate and RTT is then fed to TCP throughput equation at senders end to calculate the TCP 
friendly rate. Sender then adjusts its sending rate according to this calculated rate. TFRC provides 
smooth sending rate while still providing sufficient responsiveness to competing traffic 

A. Improvements of TFRC 

The original specification of TFRC-RFC 3448 is suited for many multimedia streaming 
applications when continuous flow of data is available at sender. It is not useful for the 
applications like voice over IP (VoIP) and video conference characterized by periods of higher 
(but limited) transmission rate, separated by periods in which much less (which we call 'data- 
limited'), or without transmission of data ( which we call 'idle periods'). This type of applications 
required variable media rate at senders. 

TFRC(RFC 3448) starts transmission with slow start maximum of 1 packet per RTT and 
terminated with the first loss event. It adjusts its sending rate according to the calculated 
throughput equation by receiver. During slow start for the first few RTTs sending rate will be less 
than media rate and this delay is called start-up delay. During an idle period (no data can be 
transferred) for a period of 4RTTs, TFRC reduces the allowed sending rate by one half for every 
no feedback timer expiry (4RTT). The rate can be reduced to minimum of 2 packets for each 
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RTT. When the application restarts (starts sending data) TFRC must slow start back from idle 
period rate to the given rate. It takes time to recover from idle period to maintain media rate. 

DCCP provides features of unreliable flow of datagram's with acknowledgements, 
reliable handshake for connection setup and teardown. DCCP working group also updated the 
algorithms in RFC 3448, leading to RFC 5348. It is intended to provide better support to 
streaming media applications like voice over IP (VoIP) and video conference during data limited 
and idle periods. RFC 5348 can share bandwidth fairly with the TCP based applications. 

In TFRC (RFC 5348) during slow-start phase, the initial rate of the sender was increased 
to 4 packets per RTT. The behavior after an idle period was updated in the absence of loss, the 
sending rate is not reduced below 4 packets per RTT or equal to the initial rate. After idle and 
data-limited period double sending rate is not limited by receiver rate. 



B. QOS requirements of VoIP and Video conference 



Voice over IP and video conference both are two-way interactive applications that 
function within time frame that the user senses as immediate (or) current. 
Three quality factors are required for both VoIP and video conference. 

• Loss should be no more than 1 percent. ^H^^ 

• One-way latency should be no more than 150ms. 

• Jitter should be no more than 30ms. ^^^^^ m Wk M Ij 

J 3. METHODOLOGY JljUFH 1 | pL ^ 

To test and compare the performance of DCCP (TFRC) protocol, the network simulator 
NS-2, version 2.34 is used. The network model used in simulation is composed by mobile nodes 
and links that are considered wireless. Each node considered as communication end-point is host 
and a forwarding unit is router. 

In addition to NS-2, a set of tools, mainly Bash scripts and AWK filters, to post-process 
the output trace files generated by the simulator are developed. In order to evaluate the 
performance, multiple experiments have been set up. 

A. Metrics 

Packet Delivery Ratio: This is the ratio of total no of packets successfully received by the 
destination nodes to number of packets sent by the source nodes throughout the simulation. 
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End-to-End Packet Delay: It is the cumulative statistical measure of the delays experienced by 
packets traveling between source and destination. 

4. SIMULATION RESULTS: 
A. Fairness of TFRC with TCP 

In this section TFRC (RFC5348) is compared with TCP by operating both at the same 
time. Packet size of TFRC and TCP is same i.e., 1000 bytes. Here 6 connections for TFRC and 1 
connection for TCP in congested network. 

Table 1 . Comparison of TFRC with TCP 
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Figure 1 . 1 : Comparison of Packet delivery ratio of TFRC and TCP 
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Figure 1. 2 :End-to-End Packet Delay of TFRC and TCP 



The results show that TFRC shares bandwidth fairly with the TCP. The packet delivery 
ratio metric is plotted in Fig. 1.1 On X-axis (TFRC rate) are represented. Table 1.1 presents the 
more detailed results. End-to-End delay results are shown in Fig. 1.2. The interesting observation 
to be made is TFRC also reduces the data rate in reaction to congestion and hence is fair to TCP. 



B . Performance of TFRC 



The following results show the Packet Delivery Ratio and End-to-End Packet Delay of 
TFRC and UDP at constant bit rates of 1Mb, 5Mb and 10Mb of continuous flow in wireless 
environment with packet size 1000. 
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Figure2.1: Packet Delivery Ratio at 1Mb data 
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Figurel.2: Packet Delivery Ratio at 5Mb data rate 




Figure2.3: Packet Delivery Ratio at 10Mb data rate 
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Figure2.4: End-to-End Packet Delay at 1Mb data rate 
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Figure2.2: End-to-End Packet Delay at 5Mb data rate 




Figure2.6: End-to-End Packet Delay at 10Mb data rate 



Table2.1: Packet Delivery Ratio of TFRC and UDP at rate 1Mb 
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Table2.2: Packet Delivery Ratio of TFRC and UDP at rate 5Mb 
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Table2. 3 : Packet Delivery Ratio of TFRC and UDP at rate 1 0Mb 
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B . Video performance 

This section analyzes the performance of Video quality using variable bit rate. It is 
initially set to 1Mbps, at 20 seconds set rate is minimum rate of 100kbps, at 50 seconds set rate is 
1.5Mbps and at 80 seconds set rate is 512Kbps. A packet size of 1000 bytes is taken. 
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Figure3.1: Packet Delivery Ratio of TFRC and UDP 




Figure3.2: End-to-End Packet Delay of TFRC and UDP 
The following tables show the packet delivery ratio of TFRC and UDP with two 
connections in more detailed results. ^^P^ 

Table3. 1 : Packet Delivery Ratio of TFRC and UDP at variable bit rate 
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5. CONCLUSION 

TFRC operated along with TCP can share band width fairly. The performance results 
show that smooth transmission of sending rate of TFRC(5348) compare with UDP, where it 
continue to send at original rate. The specification in RFC 3448 poorly supported for Real Time 
applications where padding can be used to guarantee the required media rate for RTA 
applications. Where RFC5348 does not require padding, which consumes unnecessary network 
capacity. RFC 5348 also increases the sending rate compared to RFC 3448. We therefore expect 
this new standard to further encourage the use of a standards-based congestion control for Real 
Time Applications. 
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